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IMS Signaling Architecture 



EXECUTIVE SUMMARY 



The Internet Protocol (IP) Multimedia Subsystem (IMS) is a standard, IP-based communications 
network that provides a network-independent, common service delivery environment for both 
wireless and fixed network users. IMS standards define common signaling and medio interfaces 
that ore open, vendor independent, and abstract the underlying network complexities. 

The progress towards IMS-based all-IP networks will be evolutionary. For the foreseeable 
future, IMS-based networks will coexist with traditional CS networks such as Global System for 
Mobile (GSM) and Public Switching Telephone Network (PSTN). Therefore, it is critical for the 
IMS to provide signaling gateways for interworking between SS7 protocols (e.g.. Transaction 
Capability Application Port (TCAP)-based protocols) and SIP or Diameter. This paper 
describes a number of such gateways. 



This paper introduces IMS network architecture, signaling interfaces, functions, and example 
procedures in four IMS architectural groups: IMS Core, IMS Service Delivery, IMS and 
Circuit-Switched [CS) Network Interworking, and IMS Charging. The IMS's nervous system is 
comprised of the Session Initiation Protocol (SIP) and Diameter-based signaling networks. This 
paper elaborates how IMS network elements interact with each other and provide signaling 
functions through these two key protocols. 



This paper also describes how Signolwore, on industry-proven, carrier-grade, highly available 
and scalable signaling middleware platform, supports virtually every IMS signaling network 
element and interface with its feature-rich SIP, Diameter, and SS7 protocol stacks. Backed 
with its superior platform management mechanisms, the IMS-Ready Signolwore platform 
provides Network Equipment Providers (NEPs) with unique advantages in rapid time-to- 
market, fault resilience, modular scalability, portability, maintainability, and network 
interoperability for developing and deploying IMS elements and services. 
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^ /I In'troduc'tion 



This paper introduces the IMS signaling architectures, interfaces, and functions, and addresses the 
Signaiware platform's readiness for supporting IMS signaling network elements and interfaces. The 
purpose of this whitepaper addresses IMS signaling networks at a reasonably technical level of detail; 
prior knowledge of SIP, Diameter, SS7 networks, and mobile networks will help understand the technical 
details. 



Section 1 presents the purpose, audience, and scope of this paper. 

Section 2 introduces the background of the IMS, including IMS concept and status of IMS 
standards and industry deployments. 

Section 3 presents IMS signaling network architectures, interfaces, element functions, and 
example procedures. The IMS is divided into four architectural groups: IMS Core, IMS Service 
Delivery, IMS-CS Interworking, and IMS Charging. 

Section 4 discusses a number of signaling gateways that may be needed for IMS and SS7 
network interworking. 

Section 5 addresses the IMS-Ready Signaiware platform architecture and presents the benefits 
that the Signaiware platform provides to NEPs in developing and deploying the IMS. 

Section 6 lists standard documents and information sources referred to in this paper. 

Appendix A lists references used in the writing of this paper. 

Appendix B summarizes those IMS network elements and Interfaces that Signaiware supports. 

Appendix C lists acronyms and their corresponding descriptions. 
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Background 
S/l IMS Concept: 

The IMS is a standard, IP-based communications network that presents wireless and wireline users with a 
variety of multimedia services, including voice, video, image, text, and data [1]. IMS-based wireless 
services can be classified into three categories: 



• Non-real-time services such as rich media messaging and multimedia content delivery 

• Near-real-time services such as Push-to-Talk over Cellular (PoC) and interactive gaming 

• Real-time services such as Packet-Switched (PS) audio/video telephony 
and conferencing 

These services may be facilitated via other generic services such as presence service and group list 
management service. 



Fixed and mobile communication networks are converging into IMS-based all-IP networks. To meet this 
trend, an IMS network is defined in a horizontal architecture, which comprises three functional layers [see 
Figure 2-1 ) [2] [3]. The first layer is the bearer layer, which transports signaling traffic and media streams. 
This layer contains switches, routers, and media-processing entities [e.g., media gateways and media 
servers). As it is access network-independent, an IMS can be connected to different types of existing and 
emerging access networks as long as they have IP connectivity. These include: 



• 3rd Generation networks (3G, e.g., Universal Mobile Telecommunications 
System (UMTS)) 

• 2.5th Generation networks (2.5G, e.g.. General Packet Radio Service [GPRS)) 

• 2nd Generation networks (2G, e.g., GSM) through gateways 

• Emerging wireless IP networks such as the Wireless Local Access Network (WLAN) and the 
Worldwide Interoperability for Microwave Access (WiMax) 

• PSTN through gateways 

• Residential fixed networks such as Digital Subscriber Line (DSL) and broadband cable 

• Enterprise fixed networks via IP Centrex 

The second layer in the IMS architecture is the control layer, which contains signaling network elements 
[e.g.. Call Session Control Function [CSCF], Home Subscriber Server (HSS), Media Gateway Control 
Function (MGCF)) for supporting common session control, media control, and access control functions 
through signaling protocols such as SIP, Diameter, and H.248. The control layer forms the core of the IMS, 
with which communications are effectively controlled for user devices attached to different types of 
access networks. 



The third layer in the IMS architecture is the service layer, which contains Application Servers (ASs), such 
as SIP AS, third party Open Service Access (OSA) AS, and legacy Service Control Point (SCP). IMS 
conducts service control through subscribers' home networks and those signaling network elements 
distributed in the service layer and the control layer. This enables subscribers to receive the same types of 
services while they are roaming. 



Since it provides a single core network of a horizontal structure for different types of access networks and 
services, the IMS architecture has a clear advantage over a traditional vertical service architecture, 
which duplicates the same functions (e.g., session control, charging) for each type of access and 
service. The IMS architecture creates attractive resource sharing and cost saving opportunities for 
network operators and service providers. 
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Figure 2-1 Horizontal Layered IMS Architecture 



The IMS's nervous system is its signaling network, which is enabled by two key signaling protocols: SIP and 
Diameter. SIP is used for multimedia session setup, maintenance, and teardown [1 4], while Diameter is 
used for Authentication, Authorization, and Accounting (AAA) of user services [15]. Compared to 
traditional SS7 signaling protocols [which are used for CS voice service), SIP functionally corresponds to 
ISUP, while Diameter and its applications correspond to TCAP-based protocols. To transport IMS signaling 
protocols, the Stream Control Transmission Protocol (SCTP) or the Transmission Control Protocol (TCP) 
running on top of IPvó is used. Most early IMS networks use SCTP as the preferred reliable protocol. During 
the transition period, IPv4 may be used in the initial IMS deployment as well [13]. One critical issue to the 
IMS is security, which can be ensured via the mandatory network layer security [i.e., IP Security or IPsec), 
via the optional Transport Layer Security [TLS), and via the application layer security (e.g., the Hyper Text 
Transfer Protocol (HTTP) Digest Authentication for SIP). 

S.S IMS St:andards 



A number of standards organizations are contributing directly or indirectly to the development of IMS 
standards. The Third Generation Partnership Project (3GPP) is the main organization responsible for 
developing the standards, including architecture, interfaces, network element functions, and procedures 
[1][2]. Initially defined for GPRS and UMTS networks, IMS standards are largely reused by 3GPP2 for 
defining the Multimedia Domain (MMD) in Code Division Multiple Access 2000 [CDMA2000) networks [1 1]. 
Moreover, the IMS is being adopted by the European Telecommunications Standards Institute (ETSI) as 
the standard SIP-based architecture for wireline multimedia service networks [12]. 



The 3GPP specifies an IMS network and service infrastructure, while the underlying IP-based protocols 
such as SIP and Diameter are defined in the IETF. The service specifications, such as PoC, are generated 
in the Open Mobile Alliance (OMA). Both the 3GPP and the OMA have made private extensions to IETF 
protocols used in the IMS (e.g., P-headers in SIP, Attribute-Value-Pairs (AVPs) in Diameter applications). 
While the major parts of the IMS standards have been established through two phases of 3GPP 
specification development (Release 5 and Release ój, continuous efforts are being made towards their 
completeness and maturity. 
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Although the IMS was originally specified for 3G mobile networks, it indeed provides ideal common 
service deployment infrastructure for all-IP wireline and wireless networlcs. 



Migration to all-IP based network services will be an evolutionary process. Initial IMS deployments 
include non-real-time services (e.g., multimedia content delivery) and near-real-time services (e.g., 
PoC). Due to limited deployment of high bandwidth radio access networks, IMS-based real-time 
services (e.g., Voice over IP (VoIP), video call) are not yet available in the mass market. Early IMS 
network operators plan to provide a comprehensive suite of multimedia services using WLAN for 
hotspot areas and plan to provide non- or near-real-time services using existing PS networks for 
large mobility areas. In addition, carriers are planning to offer hosted services (e.g., unified 
messaging, Virtual Private Network [VPN], and ad hoc conferencing) through IMS to large corporate 
enterprise networks. 



Network operators have already made significant investments in 2G and 2.5G networks. To maximize 
the usage of existing networks, they would prefer an incremental approach when adding new network 
subsystems into IMS-based, converged networks. To realize the benefits of IMS, they must deploy 
gateways to support interworking between different types of signaling and media networks. 
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IMS Signaling Archit:ect:ure 



Like SS7 signaling networks in traditional CS networks, SIP and Diameter-based signaling networks provide 
the IMS fundamental signaling functions for session and service control. IMS signaling network elements 
reside in the control and service layers, and can be divided into the following four architectural groups, 
each of which has specified roles [2] [3] [4]: 



• IMS Core architecture, which routes SIP messages, control multimedia sessions, and 
accesses/stores subscriber information. It resides in the network control layer and interacts with 
the other three groups. 

• IMS Service Delivery architecture, which provides enhanced IMS services and mobile IN-like 
services. It resides in the service layer and interacts with the IMS Core network. 

• IMS-CS interworking architecture, which supports signaling protocol interworking between IMS 
and CS networks. It resides in the network control layer and interacts with the bearer layer. 

• IMS charging architecture, which provides offline and online charging functions for IMS services. 
It resides in the service layer and interacts with network elements in the control layer as well as in 
the service layer. 

The following subsections elaborate signaling system architectures and functions residing in these 
four groups. 

3.^ IMS Core Arcliit:ect:ure 



The IMS Core architecture is a SIP and Diameter-based signaling network [2] [14] [15]. It is comprised of 
three types of SIP proxy servers or CSCFs: Proxy-CSCF (P-CSCF), Interrogating-CSCF (l-CSCF), and Serving- 
CSCF (S-CSCF). The IMS core also includes two types of Diameter servers: a Home Subscriber Server (HSS) 
for storing subscriber data and a Subscription Locator Function [SLF) for storing HSS addresses. Rgure 3-1 
shows the IMS Core architecture. Note that in this figure [and in the subsequent figures), a label outside 
the parentheses indicates an interface name, while a label inside the parentheses indicates the protocol 
used for this interface. 
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Figure 3-1 IMS Core Architecture 



The P-CSCF is the first contact point within an IMS Core. It maintains a security association between itself 
and each User Equipment (UE) using IPsec, performs SIP [dejcompression using the Signaling Compression 
(SigComp) mechanism [18], and provides information to a Policy Decision Function [PDF) for resource 
authorization and Quality of Service (QoS) control. The P-CSCF also relays SIP messages between UEs and 
l/S-CSCFs. Note that the PDF, which is not shown in the figure, may be part of the P-CSCF or a standalone 
entity. It interacts with the P-CSCF via the Diameter-based Gq interface and with the Gateway GPRS 
Support Node (GGSN) via the Common Open Policy Service (COPS) protocol-based Go interface. 



The l-CSCF is an optional contact point within an operator's network for all connections destined for a user of 
that network operator. It forwards S!P messages to one of the S-CSCFs, which is selected according to 
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information queried from an HSS through the Diameter-based Cx interface. If multiple HSSs are deployed in the 
IMS Core, the l-CSCF needs to first contact the SLF through the Diameter-based Dx interface, in order to get the 
address of an HSS for serving the user. (NOTE: The SLF is a Diameter Redirect Agent and can be optional.} The I- 
CSCF can be used to hide the configuration, capacity, and topology of the network from the outside. 



The S-CSCF is the pivotal element in the IMS and performs session control and registration services for 
home subscribers. It may serve as a SIP proxy to relay SIP messages, as a SIP User Agent (UA) to initiate 
or terminate SIP transactions, and as a SIP registrar to authenticate users during their registrations. The S- 
CSCF retrieves subscriber information (e.g., authentication vector, user profile] and gets notified of 
subscriber information change from the HSS through the Cx interface. 



The IMS supports roaming services via a P-CSCF in a roomer's visited network, which routes SIP messages 
to the roomer's S-CSCF in the home network. Both the S-CSCF and the P-CSCF maintain session timers 
(i.e., they are stateful proxies). All the CSCFs generate Charging Data Records (CDRs). Depending on 
deployment needs, these three types of CSCFs may be distributed into three different physical entities or 
may be consolidated into one or two entities. 



The HSS is a stateless Diameter server, which stores subscribers' profiles (e.g., user identities), registration 
(e.g., location and authentication parameters), and service logic information [e.g., filtering criteria and 
trigger points) information. It may also support Home Location Register/Authentication Center (HLR/AuC) 
functionality and Mobile Application Part [MAP)-based interfaces for legacy 2G and 2.5G networks. 
Subscriber data stored in the HSS is the key enabler for service mobility across different types of access 
networks and user roaming between different network operators. 



To describe SIP and Diameter-based signaling procedures in the IMS Core, two examples are given 
below. The first example shows an initial registration procedure (see Figure 3-2) [5], which assumes the 
user roams to a visited network. This procedure starts with the user's SIP REGISTER request being sent to 
the visited P-CSCF. Due to air interface bandwidth limitation, messages are compressed before being 
sent out by the user and are decompressed at the P-CSCF. If multiple S-CSCFs exist in the user's home 
network, an l-CSCF needs to be deployed for selecting an S-CSCF for serving the user session. In this case, 
the P-CSCF resolves the address of the user's home l-CSCF using the user's home domain name and 
forwards the REGISTER to the l-CSCF. After the l-CSCF sends a User-Authorization-Request (UAR) to the 
HSS, which returns available S-CSCF addresses, the l-CSCF selects one S-CSCF and forwards the 
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Figure 3-2 Signaling Message Flow of Registration 
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REGISTER message. Upon receipt of the REGISTER, the S-CSCF retrieves authentication vectors from the 
HSS via a Diameter Multimedia-Authentication-Request [MAR) and then returns to the user a SIP 401 
Unauthorized message which carries the authentication challenge data. After computing an 
authentication response, the user sends to the S-CSCF another REGISTER message carrying the challenge 
response. The S-CSCF verifies the response and if it is correct, downloads the subscriber profile from the 
HSS via a Diameter Server-Assignment-Request (SAR). The S-CSCF may then contact an AS for service 
control as specified in the subscriber profile, before returning a 200 OK message to the user. 
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Figure 3-3 Signaling Message Flow of Session Setup 

The second example shows a signaling flov^ for a session setup betv^een two IMS users (see Figure 3-3) 
[2] [5], assuming multiple S-CSCFs are deployed. A session setup procedure is a process of discovering 
network elements and signaling paths. When routing the INVITE message, the callee's l-CSCF interrogates 
the callee's HSS for the address of an assigned S-CSCF via a Diameter Location-Info-Request (LIR). The 
HSS responds with a Diameter Location-Info-Answer (LIA). Before forwarding the INVITE message, the 
caller's and the callee's serving S-CSCFs may interact with application servers for service control 
according to the service logic downloaded during user registration. Address resolution and standard SIP 
routing mechanisms are used to route the INVITE message from the caller's UE all the way to the callee's 
UE. The discovered path is caller's UE® caller's visited P-CSCF® caller's serving S-CSCF® callee's 
l-CSCF® callee's serving S-CSCF® callee's visited P-CSCF® callee's UE. The messages returned from the 
callee's UE (e.g., 1 83 Session Progress) follow the reverse path. Note that an offer-answer-based session 
negotiation procedure is also conducted in the meantime. This is achieved via the Session Description 
Protocol (SDP) carried in SIP message bodies (e.g., INVITE with an offer and 200 OK with an answer) [6]. 

3.S IMS Service Delivery Arcliit:ect:ure 

The IMS provides enhanced, value-added IM services via the IMS Service Delivery network, which 
comprises S-CSC\^. AS, Media Resource Function (MRF), and HSS. Figure 3-4 illustrates the network 
architecture [2], where the S-CSCF acts as the central session control point, the ASs and the MRF are 
service execution points. 
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Figure 3-4 IMS Service Delivery Architecture 



The IMS conducts home network-based service control. That is, a subscriber's S-CSCF interacts with 
service platforms through the SIP-based, intra-operator interface, named the IMS Service Control (ISC). 
To control dynamic behaviors of the ISC interface, both the S-CSCF and the AS maintain transaction 
state models for each incoming leg and each outgoing leg. The S-CSCF also maintains session state 
models for incoming and outgoing legs towards other SIP session control entities (e.g., another S-CSCFJ 



To perform a service logic control for a subscriber, the S-CSCF checks received SIP requests (e.g., INVITE) 
against extensible Markup Language (XML)-encoded service trigger points [filter criteria), which are part 
of the subscriber's service profile retrieved from the HSS during user registration. The information that is 
checked includes SIP method type, headers, Request-URI, and session description. If a trigger point is 
met, the S-CSCF will select an AS and route the SIP request to the AS in which the service is executed. 



In the IMS, the following three types of service delivery platforms interface with the S-CSCF via the ISC: 



OSA AS, which resides in another network domain and interacts with the S-CSCF through an OSA 
Service Capability Server (SCS). With a standard OSA API, the SCS gateway ensures that the 
third-party AS can securely provide value-added services to home network subscribers. 

Legacy SCP, which resides in an SS7 network and interacts with the S-CSCF through an IM Service 
Switching Function (IM-SSF). Leveraging legacy Customized Applications for Mobile network 
Enhanced Logic (CAMEL) infrastructure and the IM-SSF, IMS network operators are 
able to cost-effectively provide IMS users with existing mobile IN services (e.g., prepaid 
service control). 

SIP AS, which resides in the home network and provides SIP-based services (e.g., presence, 
instant messaging). Depending on whether an AS originates, terminates, or relays SIP dialogs, 
a SIP AS may act as a UA, a Back-To-Back UA (B2BUA), or a proxy server. As an example. Figure 
3-5 shows a message flow for a presence server-related procedure, where user A subscribes to 
the presence information of user B, and the presence server acts as a UA. 
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Figure 3-5 Message Flow of User A Subscribing to Presence Information of User B 



Besides interfacing with the S-CSCF, these three types of application servers also interface with the HSS 
Three types of Interactions exist between the HSS and the various ASs, as shown In Figure 3-4. 



1 . The SIP AS and the OSA SCS nnoy obtain subscribers' data (e.g., location information) actively 
(pull) or passively (push) from the HSS through the Diameter-based Sh Interface in a similar 
fashion to the S-CSCF. Figure 3-6, which Is self-explanatory, Illustrates a message flow for 
Interactions between an AS and an HSS through this Interface. 

2. If multiple HSSs are deployed then In a manner similar to an l-CSCF contacting an SLF via the 

Dx Interface, an AS may obtain HSS addresses from the SLF via the Diameter-based Dh Interface 
before contacting an HSS. 

3. In order to arm those trigger points In the call state models, the IM-SSF downloads the 
subscriber's service profile from the HSS/HLR through the MAP-based SI Interface. 
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The AS requests subscriber data via User- 
Data-Request (UDR) and receives data 
in UDA. 

The AS subscribes for notification of user 
data changes in the HSS using 
Subscriber-Notification-Request (SNR) 
and gets confirmation In SNA. 

Upon user data change in the HSS, the 
AS gets notified via Push-Noilfication- 
Request (PNR) and responds with PNA. 

The AS updates user data in the HSS 
using Profile-Update-Request (PUR) and 
gets confirmation in PUA. 



Figure 3-6 Message Flow of AS Interacting with HSS via Sh Interface 
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In addition to application servers, the IMS defines a special type of Media Resource Function, or MRF, 
which interacts with the S-CSCF and supports interactive media services such as announcement, PoC, 
and conferencing. An MRF comprises an MRF Controller (MRFC) and a MRF Processor (MRFPJ with the 
former controlling the latter for media processing via the H.248 protocol. The MRFC is a SIP UA and 
interfaces with the S-CSCF using the Mr interface. When an MRF provides a media service, another AS 
may be used to support supplementary services for the MRF (e.g., conference booking) through the S- 
CSCF. As an example, Figure 3-7 depicts a PoC session setup procedure for a one-to-one conversation, 
assuming the inviting user and the invited user have the same home network and are currently in their 
home network [13]. Upon completion of this procedure, both the inviting UE and the invited UE establish 
sessions with the PoC server [i.e., the MRF). 
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Figure 3-7 PoC Session Setup Signaling Flow for a One-To-One Conversation 

3.3 IMS-CS lnt:erv\/orking Archit:ect:ure 

Traditional CS (e.g., PSTN, GSM) voice service will coexist with PS multimedia services for the foreseeable 
future. Therefore, it is critical to provide interworking between IMS and CS-based voice services. To this 
end, the IMS provides a distributed softswitching architecture (see Figure 3-8], which comprises the 
following network elements [2]: 
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Figure 3-8 IMS-CS Interworking Architecture 
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Signaling Gateway (SGW), which converts the transport of the ISDN User Part (ISUP) protocol 
between Message Transfer Part 3 (MTP3) and MTP3 User Adaptation [M3UA}. 

lAA Media Gateway (lAA-MGW), which converts media format provided in one type of network to 

the format required in another type of network [e.g., from the Time Division Multiplexing (TDM)- 
based format to the IP-based format). 

Media Gateway Control Function (MGCF), which acts as a SIP UA and translates signaling 
messages between SIP and ISUP. It also controls the media conversion in one or multiple IM-MGWs 
using the media gateway control protocol, H.248, according to received ISUP or SIP messages. 

Breakout Gateway Control Function (BGCF), which determines where the interworking should 
occur when a session is originated from an IMS user. If the interworking occurs in the same 
network, the BGCF will select an MGCF; otherwise, it contacts a BGCF belonging to another 
network (operator), where the interworking will take place. 
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Figure 3-? Call Setup Message Flow with an IMS User Calling a CS User 



As an example, a session setup signaling flow with an IMS user calling a CS user is illustrated in Figure 3-9 
[1 6], assuming both the caller and the callee have the same home network. This procedure starts when 
the IMS user agent sends a SIP INVITE message with the Request-URI of the TEL-URI format. Upon receipt of 
the INVITE message, the S-CSCF contacts an Electronic Number (ENUM) server in order to convert the 
destined TEL URI into a routable SIP URL If the TEL URI is not stored in the ENUM Server (indicating the 
callee is not an IMS user), the S-CSCF will forward [via the Mi interface) the INVITE message to a BGCF, 
which determines the breakout should occur in the same network for this example. The BGCF selects an 
MGCF and forwards the INVITE message via the Mj interface. The MGCF first demands the IM-MGW to 
allocate media resource for the IMS user, and then sends a corresponding ISUP IAM message to the SGW 
using the M3UA as the transport. The same message is sent to the SS7 network from the SGW but using 
the MTP3 as the transport. After the IAM message is delivered to the SS7 network, ACM and ANM 
messages are normally returned to the MGCF, which sends to the IMS users the corresponding 180 ringing 
and 200 OK messages. Note that when the IMS user receives a provisional response (e.g., SIP 1 80 or 1 83), 
the user will return a SIP PRACK message in order to reliably acknowledge the response. 
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3.4 IMS charging Archit:ect:ure 

The IMS supports both offline charging (postpaid) and online charging (real-time prepaid] services. Figure 
3-10 shows the IMS charging architecture, where two types of application servers in the IMS service layer 
are provided to support charging functions [6] [7]. These include the Charging Collection/Data Function 
(CCF in Release 5, CDF in Release 6) for the postpaid service and the Online Charging Function (OCF) for 
the real-time prepaid service. The addresses of these charging functions can be configured locally in IMS 
elements or be obtained from the P-Charging-Function-Addresses header carried in SIP messages. 
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Figure 3-10 IMS Charging Architecture 

As shown in Figure 3-10, the IMS elements interfacing with the CCF/CDF via this interface include the P- 
CSCF, l-CSCF, S-CSCF, BGCF, and MGCF. The offline-charging interface to these elements is the Diameter 
accounting-based Rf interface [9] [1 5] . The CCF/CDF is a stateless Diameter AS, which does not maintain 
session states but only transaction states. Depending on received signaling messages, an IMS element will 
send the CCF/CDF a corresponding Diameter Accounting Request (ACR) message for start, interim, stop, 
and event of accounting operations. The CCF/CDF creates or updates CDRs based on these accounting 
messages. As an example. Figure 3-1 1 shows an offline charging message flow between a CSCF and a 
CCF/CDF during the lifecycle of a session. In this procedure, an ACR-start is triggered upon receipt of a 
200 OK (for an INVITE) message, an ACR-interim is sent upon expiration of the interim duration (specified 
in the interval AVP), and an ACR-stop is triggered upon receipt of a BYE message for the session. 
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Figure 3-1 1 Signaling Flow for a Session-Based Offline Charging 
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The online-charging interface (or Ro interface) is an extension to the IETF Diameter Credit Control 
Application [9][1 7]. As shown in Figure 3-10, the IMS elements interacting with the OCF via this interface 
include the S-CSCF, SIP AS, and MRFC. The S-CSCF interacts with the Session Charging Function (SCFJ of 
the OCF for session-based prepaid service control, while the SIP AS and the MRFC interact with the Event 
Charging Function (ECF) of the OCF for content-based prepaid control. There exists a SIP and Diameter 
Interworking Function (IWF) between the S-CSCF and the SCF, which maps signaling messages between 
SIP and Diameter. This SIP-Diameter IWF may be a standalone entity or be collocated with the S-CSCF. 
NOTE: This IWF is not currently standardized in the 3GPP. 



The OCF is a stateful Diameter AS, which maintains both session states and transaction states. Depending 
on the received SIP messages and the service usage condition, a credit control client [e.g., SIP-Diameter 
IWF) will send Diameter Credit-Control-Request (OCR) messages to the OCF for allocating or returning 
(unused) monetary units or non-monetary service units (e.g., volume, duration). Depending on a 
subscriber's account balance, the OCF returns corresponding Credit-Control-Answer (CCA) messages for 
granting service units or rejecting the request. As an example. Figure 3-12 shows a session-based online 
charging message flow (NOTE: This message flow is not from a standard document, but is created by the 
author). During this control procedure, the IWF maintains interworking state models and sends out 
Diameter messages based on current states and received SIP messages. More specifically, it sends the 
SCF a CCR-lnitial-Requesf upon receipt of a SIP INVITE message, a CCR-Update-Request when granted 
service units are going to be depleted, and a CCR-Termination-Request upon receipt of a SIP BYE 
message for the session. It should be noted that when interacting with the SIP-Diameter IWF, the S-CSCF 
acts as a proxy and forwards all the received SIP messages, while the SIP-Dlameter IWF in turn routes the 
same message back to the S-CSCF after necessary trigger point processing. 
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Figure 3-12 Signaling Flow for a Session-Based Online Charging 
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4. 



IMS Signaling (3at:e\A/ays 



The progress towards IMS-based all-IP networks is evolutionary. For the foreseeable future, 
communication networks will cohabit ate in a heterogeneous environment comprised of fixed and 
mobile, CS and PS networks. There will be a variety of network interworking scenarios that require 
different types of signaling gateways. In general, signaling gateways will be needed for the following 



purposes: 



Support roaming between IMS and CS networks with gateways such as IMS-GSM 
Mobility Gateway 

Support IMS and CS interworking with gateways such as Signaling Transport [SIGTRAN] Gateway 
and SIP-Short Message Service [SMS) Gateway 



• Leverage or reuse legacy mobile IN infrastructures and databases with gateways such as SlP-to- 
CAP Gateway and SIP-to-TCAP Gateway 

The following subsections introduce a number of signaling gateways for various deployment 
environments and usage scenarios. 

4.^ IMS IVIobilit:y C3at:ev\/ay 

A user with a dual-mode handset capable of receiving either a 2.5G GSM service or an IMS service (e.g., 
using a WLAN network as the access) may roam between GSM networks and IMS networks. Similar 
services can also be provided for a CDMA device. To support such a roaming service, an IMS-GSM 
Mobility Gateway is needed when the dual mode user's HLR and HSS are not collocated. Figure 4-1 
shows a network architecture with such a gateway deployed on network borders. In this architecture, the 
IMS-GSM Mobility Gateway acts as a VLR (via the D interface) from the perspective of a Mobile 
Switching Center (MSC)/VLR, as an AS (via the Sh interface) from the perspective of an HSS, and as an 
AS (via the ISC Interface) from the perspective of an S-CSCF. 
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Figure 4-1 IMS Mobility Gateway for Dual-Mode Users Roaming between IMS and GSM Networks 

This gateway, in fact, comprises a SIP-MAP Gateway function and a MAP-Diameter Gateway function. 
The SIP-MAP Gateway function allows a dual-mode user to register with the HSS and deregister with the 
current Visited Location Register [VLR] when the user roams from the GSM network to the IMS network. On 
the other hand, it allows the user to register with a VLR and deregister with the HSS when the user roams 
from the IMS network to the GSM network. To describe the SIP-MAP Gateway function, a message flow for 
a dual-mode user who roams from a GSM network to an IMS network Is given in Figure 4-2. Upon user 
registration with the IMS network, the S-CSCF sends a SIP REGISTER message to the IMS-GSM Gateway, 
which In turn sends a MAP Update Location message to the HLR. The HLR treats the Gateway as another 
VLR; therefore. It dereglsters the user from the current VLR via a MAP Cancel Location message. 
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Figure 4-2 Message Flow of a Dual-Mode User Roaming from a GSM fo an IMS Network 
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Figure 4-3 Message Flow of a CS User Calling an IMS User 



The MAP-Diameter Gateway function allows the HLR and the HSS to query each other for the user's 
location information. To understand this function, a message flow is given in Figure 4-3. This flow assumes 
a call is originated from a CS user and is destined for an IMS user. Following a mobile termination 
procedure, the terminating Gateway MSC (GMSC) requests from the HLR the called user's Mobile Station 
Roaming Number (MSRN) via a Subscriber Roaming Information (SRI) message. The HLR considers the IMS- 
GSM Gateway as a VLR; therefore. It contacts the Gateway for the MSRN via a MAP Provide Roaming 
Number (PRN) message. The Gateway knows that the called user is in the IMS according to the response 
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from the HSS, and returns an MSRN. The GMSC then routes the ISUP IAM message to the MGCF, which 
sends out a corresponding SIP INVITE message. 

4.S SIP-t:o-TCAP C3at:e\A/ay 

In traditional SS7 networks, SCPs are deployed to support TCAP-based database query applications such as 
toll-free numbers, Caller Name (CNAM), and Local Number Portability (LNP). These existing SCPs may be 
leveraged to provide legacy SS7 applications. A SIP-to-TCAP Gateway or border element is needed to 
bridge SIP and TCAP messages between an IMS element (e.g., S-CSCF) and an SCP. The gateway acts as a 
redirect agent from the perspective of the IMS element, and as an SSF from the perspective of the SCP. 



As an example. Figure 4-4 shows a message flow for a toll-free number translation application through a 
SIP-to-TCAP Gateway. An S-CSCF sends to the gateway an INVITE message containing a toll-free number 
(TEL URI}, which is then translated into a routable telephone number through an SCP. The gateway returns 
a SIP 302 Moved Temporarily message to the S-CSCF, which contains the translated number. The IMS user 
that originates the initial INVITE message will send another INVITE with the translated number as the 
destination address. 
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Figure 4-4 Message Flow of a ToII-Free Number Appli 



through a SIP-to-TCAP Gateway 



4.3 5IP-t:o-CAP C3at:ev\/ay 



Legacy CAMEL network infrastructure supports mobile IN services such as prepaid charging, Wireless 
Number Portability (WNP), Caller Name (CNAM) presentation, and so on. In order to leverage CAMEL 
infrastructure and cost effectively provide IMS users with those mobile IN services, an IM-SSF can be 
deployed between an S-CSCF and an SCP [10]. The IM-SSF is, in fact, a SIP-to-CAP gateway that provides 
interworking functions between SIP session control and the CAMEL Application Part (CAP) state models. On 
the one hand, it interacts with an S-CSCF via the ISC interface and acts as a SIP AS. On the other hand, it 
interacts with an SCP via the CAP interface and acts as an SSF. The IM-SSF can be a standalone entity or a 
function integrated into an S-CSCF. 

The working scenario of the IM-SSF is as follows. During user registration, it downloads triggering point 
information from the HSS/HLR through the MAP-based Si interface [see Figure 3-4), and arms IM Basic Call 
State Models (IM-BCSMs) accordingly. During the lifecycle of a SIP session, the IM-SSF maintains an originating 
or a terminating IM-BCSM and conducts service control. That is, based on armed trigger points in an IM- 
BCSM, the IM-SCF sends CAP requests to the SCP upon receipt of triggering SIP messages from the S-CSCF. 
As an example. Figure 4-5 illustrates a message flow for an online charging [prepaid) control procedure. In 
addition to CAP, SIP may be able to interwork with other TCAP-based IN protocols [based on the same 
principle), such as Intelligent Network Application Part (INAP) and Advanced Intelligent Network [AIN). 
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Figure 4-5 Message Flow of Online Charging Control with SIP-to-CAP Gateway 



4.4 SIP-to- 





SMS, which is carried over MAP protocol, is one of the most successful mobile services provided via SS7 
networks. A similar messaging service is supported via IMS networlcs as well. IMS-based messaging 
includes a pager mode service and a session mode service. The pager mode is used to send text 
messages with a limited size, which corresponds to SMS, while the session mode is used to send 
multimedia messages, and needs to transfer messages within an established session. 
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Figure A-& Inferworking Architecture of SIP and SMS 



When an SMS user and an IMS user exchange short messages, a SIP-SMS Gateway is needed. This paper 
proposes the network architecture with a SIP-SMS Gateway for bridging SIP and SMS messages as shown 
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in Figure 4-6. In this architecture, the SIP-SMS Gateway acts as an MSC from the perspective of an SMS 
Center (SMSC), and as a SIP AS from the perspective of an S-CSCF and from the HSS/HLR. As an example, 
Figure 4-7 shows a message flow with an SMS user sending a short message to an IMS user. In order for 
the HSS/HLR to know the Gateway address, upon IMS user registration, the Gateway needs to inform the 
HLR of its address via the Diameter-based Sh interface [as shown in step 4). 
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Figure 4-7 Message Flow of an GSM User Sending a Shorf Message to an IMS User 
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IMS-Ready Signalv\/are Plat:form 

IMS plays a pivotal role in the convergence of wireless and fixed networks. Ulticom's IMS-Ready™ 
Signaiware products are in the forefront to support signaling network elements in IMS-based, converged 
networks. Ulticom is well positioned to provide a carrier-grade, IMS service-enabling, signaling 
middleware platform. 

Signaiware is an industry-proven, carrier-grade, highly available, and modularly scalable signaling 
application development and execution platform. It provides a rich suite of signaling protocol offerings 
and a reliable system development and execution environment. Figure 5-1 illustrates the Signaiware IMS 
platform architecture; the shaded components are available from Ulticom today. 
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Figure 5-1 IMS-Ready Signaiware Platform Architecture 

As shown in the architecture, Signaiware supports a full range of signaling protocols, including 



• SIP, for which Signaiware SIP supports both specifications defined in the Internet Engineering Task 
Force (IETF) and private extensions defined in the 3'^ Generation Partnership Project (3GPP). 

• Diamefer, for which Signaiware Diameter supports Diameter base protocol and various 
Diameter applications. 

• SS7 protocols, for which Signaiware SS7 provides a full range of SS7, SS7/IP, and SS7/ATM protocols. 
Furthermore, Signaiware supports a wide range of global standards and national variants. 

These protocols interface with applications using Signaiware APIs. Detailed protocols offered by Ulticom 
are depicted as shaded areas in Figure 5-2. Note that Signaiware uses operating system features [e.g., 
IPsec, provided in the OS to enable security protection. With these signaling protocols and management 
environment, IMS-Ready Signaiware enables virtually all the signaling servers and gateways essential to 
IMS-based fixed and mobile converged networks. These include SIP servers. Diameter servers, signaling 
gateways, and associated interfaces. A table in Appendix A summarizes the IMS elements and interfaces 
that the Signaiware platform supports. 
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Figure 5-2 Signaling Protocols Offered in Signalware Platform 

Benef it:s of IMS-Ready 5ignal\A/are 

IMS-Ready Signalware offers the following advantages and benefits, which are critical to NEPs and 
carriers in order to successfully deploy IMS networks and services : 

• Rapid time to market, which allows faster, more cost-effective development and deployment 
of IMS networks and services with Signalware APIs, sample applications, and Ulticom's 
professional services. 

• Fault resilience, which ensures high availability [99.999%} of systems and services, and 
prevents revenue loss from down time. This level of availability is not only provided in traditional 
Signalware SS7-backed network elements, but also is ensured for IP-based signaling elements 
backed by Signalware SIP, Diameter, or combinations of Signalware SS7-based and IP-based 
signaling protocols. To achieve this, both hardware and software components (e.g., computing 
elements, software processes, network connectivity, and signaling boards) are redundant and 
actively monitored. Upon failure of one component, its backup component takes over in a 
timely manner. 

• Scalability, which enables modular increase of system capacity in order to meet different 
application and deployment needs. Signalware supports a cluster containing one to four 
Computing Elements (CEs). In order to hide server infrastructure, Signalware provides virtual IP 
features, which present a single server image to external signaling networks. 

• Portability, which facilitates systems to be ported across different operating system-based 
platforms (e.g., Solaris, Linux). 

• Network interoperability, which enables interworking between different types of networks (e.g., 
between SS7 networks and SIP networks) and between different protocol variants (e.g., between 
3GPP SIP and other SIP variants). As Signalware provides a full-fledged, hybrid, carrier-grade 
signaling platform, network interoperability is more easily achieved. 

• Maintainability, which facilitates Operations, Administration and Maintenance (OAM), and 
lowers cost of network ownership. Signalware OAM functions include provisioning, event logging, 
measurement collection, and platform management using Man Machine Language (MML), 
Graphical User Interface (GUI), and Simple Network Management Protocol (SNMP)-based 
remote access. 
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Acronym 


Descrpt on 


25 G 


2.5th General on 


2G 


Second Generaton 


3G 


Third General on 


3GPP 


Third General on Partnersh p Pro ect 


AAA 


Authent cat on. Author zot on and Account ng 


AN 


Advanced nte igent Network 


API 


App cat on Programming nterfoce 


AS 


App cat on Server 


ATM 


Asynchronous Transfer Mode 


AuC 


Authent cat on Center 


AVP 


Attr bute-Va ue-Po rs 


B2BUA 


Back-To-Back UA 


BCSM 


BascCa State Mode 


BGCF 


Breakout Gateway Contro Funct on 


CAMEL 


Customized App cat ons for Mob ie network Enhanced Log c 


CAP 


CAMEL App icai on Part 


CCF 


Charging Co ect on Function 


CDF 


Charging Data Function 


CDMA2000 


Code D vis on Mu t p e Access 2000 


CDR 


Charging Data Record 


CE 


Computing Eement 


CNAM 


Caler Name 


COPS 


Common Open Po cy Servce 


cs 


C rcuit-Swtched 


CSCF 


Ca Session Contro Funct on 


DNS 


Domain Name Server 


DSL 


D g tal Subscriber L ne 


ECF 


Event Charg ng Function 


ENUM 


Eectronc Number ng 


ETS 


European Te ecommun cations Standards nst tuie 


GGSN 


Gateway GPRS Support Node 
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GMSC 


Gateway MSC 


GPRS 


Genera Packet Pad o Servces 
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G obal System for Mob !e communicat on 
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HSS 
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nternet Engineer ng Task Force 
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nternet Protoco 
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P Mu Í med a Service Contro 
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SDN User Part 
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MTP3 User Adaptat on Layer 
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Media Gateway Contro Protoco 
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Media Gateway Contro Function 


MGW 


Media Gateway 
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Mut med a Doma n 
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MRFP 


MRF Processor 
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Mob e Subscrber Roam ng Number 


NEP 


Network Equipment Provder 
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Onine Chargng Functon 
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Onine Chargng System 
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OpenMobieA ance 


OSA 


Open Servce Access 
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Proxy CSCF 
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PDF 


Po cy Decis on Funct on 
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Packet Data Serving Node 
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Push-to-Ta k over Ce u ar 
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Pub c Sw tched Te ephone Network 


RAN 


Rod o Access Network 
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SSF 


Serv ce Sw tch ng Funct on 
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Transmiss on Contro Protoco 
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T me D v sion Mu t p ex ng 


TLS 


Transport Layer Securty 
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User Agent 


UE 


User Equipment 
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Un versa Mob e Te ecommunicatons System 


UR 
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VPN 


Vrtua Prvate Network 
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Wordwde nteroperab ty for Mcrowave Access 
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W re ess Loca Area Network 
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W re ess Number Portab 1 ty 
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